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MULTI-PLAYER GAME SYSTEM AND METHOD 

Field Of The Invention 

The present invention relates to a system and method of providing an interactive 
5 computer-hosted game to multiple players via a communications system. 

Background Of The Invention 

Computer-hosted games are popular and comprise a wide variety of game subject 
matter ranging from conventional games such as chess to more exotic games such as flight 
10 combat simulators. Traditionally, in most of these games the player competed against the 
computer, which emulated an opponent, or against another player present at the location of 
the computer, or a combination of both. 

More recently, some computer-hosted games have provided features whereby two or 
15 more players can play the game, either cooperatively or competitively, via modem-based, 
local area network based, or Internet based telecommunications links between each player's 
computer. 

While such multi-player games have enjoyed considerable success, they are relatively 
20 limited in the number of players which can participate, often allowing no more than a 
maximum of four players, and require structured telecommunications links between the 
player's computers in order to function properly. Specifically, either a dial up telephone link 
or a local area network link must be established between the player's computers so that 
rtuiumal latency and guaranteed deliverability of information through the telecommunications 
25 link is provided. . 

Particular examples of Internet-based games include Multi-User Dungeons (MUDs), 
AIR WARRIOR. WARBIRDS, SUBSPACE, and MERIDIAN 59. MUDs are text based 
games where multiple users interact, but only in small groups. Players are grouped 
30 according to the room in which the player is at any time. Only those players in the same 
room will interact with each other However, since the game is text based, latency of 

SUBSTITUTE SHEET (RULE 26) 
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transmission of information is not a problem for a smooth operation of the game. Further, 
there is usually a limit on the number of players who may enter a room at any time. 

In AIR WARRIOR. WARBIRDS. SUBSPACE and MERIDIAN 59. there appears 
5 to be no apparent limit on the number of players who may play the game at any given time, 
nor a means of assessing band width requirements and throughput. While the air space of 
the game may be logically divided, there is no control over the bandwidth of transmission. 
All information is transmitted on the assumption that all information will arrive at the 
intended destination in time. Clearly, the assumption becomes less viable as the number of 
10 payers and their level of interaction increases. 

Summary Of The Invention 

h is an object of the present invention to provide a novel multi-player game system 
and method which obviates or mitigates at least one of the disadvantages of the prior an. 

15 

It is desirable to have a multi-player game system and method which will support a 
relatively larger number of players and which does not require structured telecommunications 
links such as dial up telephone links or local area network links. 

20 According to one aspect of the present invention, there is provided a game server for 

a multi-player game system. The game server comprises: 

a game driver for executing a multi-player game and generating game information for 
playing the multi-player game by at least one game client through a telecommunication 
nerwork. 

25 prioritizing means for prioritizing the game information and responsively queuing the 

game information for transmission to the at least one game client, 

aperture control means for optimizing the game information for transmission to the 
at least one game client, and 

communications means for transmitting the game information through the 
30 telecommunication network to the at least one game client and for receiving processed user 
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input through the telecommunication network from the at least one game client and 
transmitting the processed user input to the game driver. 

According to another aspect of the present invention there is provided method of 
5 operating a multi-player game system having a game server communicating with a plurality 
of game clients connected through a telecommunications network. The method comprises 
the steps of, for each game client: 

prioritizing game information generated by a game driver executing a multi-player 

game, 

10 queuing the game information in order of priority for transmission to the game client, 

optimizing transmission of the game information to the game client, 
transmitting the game information through the telecommunication network to the 
game client, 

receiving processed user input through the telecommunication network from the game 
15 client and transmitting the processed user input to the game driver, and 
repeating the steps for playing the multi-player game. 

According to another aspect of the invention, there is provided an article of 
manufacture comprising: 
20 a computer usable medium having computer readable program code means embodied 

therein for implementing a multi-player game playable by at least one game client connected 
through a telecommunications network. The computer readable program code means in the 
article of manufacture comprises: 

computer readable program code means for causing the computer to prioritize game 
25 information generated by a game driver executing a multi-player game, 

computer readable program code means for causing the computer to queue the game 
information in an order of priority for transmission to the at least on game client, 

computer readable program code means for causing the computer to optimize 
transmission of the game information to the at least game client, 
30 computer readable program code means for causing the computer to transmit the game 

information through the telecommunication network to the at least one game client, 
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computer readable program code means for causing the computer to receive processed 
user input through the telecommunication network from the game client and to transmit the 
processed user input to the game driver. 

5 Brief Description Of The Drawings 

Preferred embodiments of the present invention will now be described, by way of 
example only, with reference (o the attached figures, wherein: 

Figure 1 shows a schematic representation of an Internet-based embodiment of the 
present invention; 

10 Figure 2 shows a block diagram of a game client for the embodiment of Figure 1, 

Figure 3 shows a block diagram of a server and game driver for the embodiment of 
Figure 1; and 

Figure 4 shows a block diagram of performance monitoring, aperture control and 
synchronization functions of the game server shown in Figure 3, 

15 

Detailed Description Of The Invention 

A multi-player game system in accordance with the present invention is indicated 
generally at 10 in Figure 1. Game system 10 includes a game driver 14 connected to one or 
more communications servers 12. Communications server 12 is connected to a 
20 telecommunication network 16 which is in turn connected to a plurality of game clients 18 
via a distribution system 20. 

In the embodiment shown in Figure 1, it is contemplated that telecommunication 
network 16 will be a data packet type network, such as an IP based network. Thus, network 
25 16 will generally comprise a variety of relatively high bandwidth point to point 
telecommunications links 22, the actual number and identity of the links 22 being subject to 
change, on a packet to packet basis, depending upon packet routing. The dynamic 
arrangement of these telecommunications links 22 is indicated in Figure I by the cloud- 
shaped block. 
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While it is contemplated that, in particular, game sysrem 10 can advantageously 
employ the Internet as telecommunication network 16. it will be apparent to those of skill in 
the art that the present invention is not limited to such use. Accordingly, other suitable 
telecommunication networks, including networks which are not packet-based, as will occur 
5 to those of skill in the art, can be employed with the present invention as desired. 

Distribution system 20 connects game clients 18 to telecommunication network 16 via 
telecommunications links 24. In the case wherein telecommunication network 16 is the 
Internet, it is contemplated that distribution system 20 will be an Internet Service Provider 
10 (ISP) or the like and telecommunications links 24 will be dial up telephone links, preferably 
with data communication rates of at least 9600 baud and higher, with higher rates being 
preferred. It is also apparent to those skilled in the art that distribution system 20 is not 
limited to a single ISP; multiple ISP's can connect other game clients 18 via separate 
telecommunications links 24. 

15 

As will be apparent to those of skill in the art, any other data transmission technique, 
such as CATV networks, ISDN or distributed fiber optic networks can be used for 
telecommunications link 24. In any case, it will be understood by those of skill in the art that 
telecommunications links 24 will be connected to game clients 18 by a suitable data interface 
20 for transmitting and receiving data. 

Each game client 18 can be any computer platform suitable for executing a game and 
maintaining a telecommunication link and such platforms include IBM PC compatible 
computer systems, Apple Macintosh computer systems, games computer systems such as a 
25 SEGA Saturn games computer, game consoles or set top consoles. 

As shown in Figure 2, each game client 18 can comprise an operating system 100, 
a communications software 102, an optional client system clock 104 or other means of 
system synchronization, game client software 106 and a game client API 108 providing a 
30 defined interface between communications software 102 and game client software 106. In 
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addition, game client 18 includes game playing input and output devices 110 to interact with 
the game player. 

Operating system 100 can be any suitable operating system which provides at least 
5 a set of basic input and output functions for the hardware platform. If an IBM PC compatible 
system is selected, operating system 100 can be a GUI-based operating system such as 
Windows 95 or OS/2 Warp, or an older operating system such as MS-DOS. If an Apple 
Macintosh is selected, operating system 100 can be Apple's System 7, etc. If a games 
computer system is selected, such as a SEGA Saturn, Nintendo Ultra or the like, operating 
10 system 100 may be rudimentary and/or specifically written to provide necessary system level 
functions for use as a component of the software of game client 18. 

Communications software 102 cooperates with operating system 100 and the 
communications hardware, such as a modem, LAN or WAN, of game client 18 to establish, 

15 maintain and utilize telecommunication link 24 to distribution system 20, Communications 
software 102 operates to receive information from communications server 12, via 
telecommunication network 16 and telecommunications link 24 and to forward this received 
information to client software 106 via client API 108. Communications software 102 also 
operates to receive information from client software 106, via client API 108, and to transmit 

20 this processed data to communications server 12 via telecommunications link 24 and network 
16. As will be apparent to those of skill in the an, the transmission of data to game client 
18 need not occur at the same rate as data is transmitted from game client 18. 

In any event, communications software 102 performs all of the functions necessary 
25 to effect the receipt and transmission of data between communications server 12 and game 
client 18, including performing the necessary steps to construct suitable packets for 
transmission and/or decode received packets for use by client software 106, including 
establishing transmission and receipt buffers or analogous means to buffer information, 
performing error correction on received packets, providing acknowledgement of packets 
30 received and/or re-sending packets, re-ordering packets, etc. A variety of known methods 
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for implementing communications software 102 will be apparem to those of skill in the art 
and thus will not be further discussed herein. 

Client software 106 is executed by game client 18 to, at a minium, receive input and 
5 provide the output necessary for a computer-hosted game to be played at game client 18. 
Depending upon the hardware capabilities of game client 18, client software 106 can produce 
a variety of suitable outputs with game playing input and outputs 1 10 including graphics, 
text, sounds, etc. Similarly, client software 106 can accept a variety of game player inputs 
via game playing inputs and outputs 110 including keyboard, joystick, games controller, 
10 mouse input, etc. 

Client software 106 performs a significant amount of processing of user input 
received from the game player via game playing input and output 110 and appropriate 
updating of output. In this manner, raw or processed user input is transmitted back to the 
15 game driver 14, limiting the amount of data to be transmitted. 

For example, in a flight simulator air combat-type game, client software 106, 
executing on an IBM PC compatible computer system, can process input received from the 
game player and produce appropriately updated graphics, status changes, sounds, etc. 

20 Specifically, client software 106 will process a user input representing an attitude change for 
the simulated aircraft through a mathematical model of the flight characteristics of the aircraft 
to determine the changes co the aircraft's resulting flight condition. The graphics displayed 
to the game player by game playing input/output 110 is then updated to reflect the 
appropriate changes to the aircraft's cockpit instruments and the view through the canopy. 

25 Further, game client software 106 can determine whether another player's shots have hit, and 
if so, determine whether the player can continue play. Accordingly, client software 106 
preferably performs a significant portion of the processing required to implement a computer 
hosted game. 

30 It is contemplated that client software 106 will be written or modified specifically for 

each game intended to be played with system 10 and to provide multi-player capabilities 
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ihrough network 16 via client API 108. Further, while in some cases client software 106 
may be stored in a non-volatile memory in game client 18, it is contemplated that in many 
circumstances diem software 106 will be transmitted to game client 18, as needed, via 
network 16. 

5 

As shown in Figure 3, communications server 12 may include one or more game 
servers 200, a server system clock 202 % and a server API 204 through which game server 
200 communicates with game driver 14. 

10 Game driver 14 includes game software 206 providing the co-ordination and 

arbitration of events resulting from the play of the game players in a particular mulri-player 
game. Game driver 14 may receive information from game clients 18 to which it is 
connected via communications server 12. The information is processed by game software 
206 to produce an appropriate output which is then transmitted to each affected game client 

15 18. For example, in an interactive air combat type game, game driver 14 may receive 
information that a player has fired a shot. After processing by game software 206, the output 
may be that the player has shot down another player at a different game client 18. Game 
driver 14 may also transmit information of a global nature to each game client 18, such as 
a transition from day to night occurring in the game. 

20 

Game driver 14 may be integrated with communications server 12. However, it is 
contemplated that game driver 14 be separate software of the multi-player game system 10. 
An advantage of separating the communications server 12 from the game driver 14 is that 
a variety of different games can be played by using different game drivers simultaneously 

25 with a single communications server 12. Additionally, one or more game drivers 14. 
responsible for a single game, may communicate with multiple communications servers 12 
to communicate with a greater number of game clients 18. However, it is apparent to those 
skilled in the art that when multiple communications servers 12 are used, the multiple 
communications servers 12 must be synchronized. Synchronization can be through a network 

30 time protocol, or independent means associated with the system. 
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Garne information, in the form of information packets, is forwarded from game driver 
14 through server API 204 to game server 200, for transmission to game clients 18. 
Associated with each information packet is a component referred to by the present inventors 
as a Relevancy Vector (RV). The RV is a logical construct which provides an indication of 
5 the importance of the information in the information packet relative to other packets intended 
for the same game client 18. In the preferred embodiment, RV's are multidimensional arrays 
of values chat can be examined by game server 200 to evaluate packets against each other to 
prioritize the packets for transmission. The information packets with the highest RV values 
are inserted into a queue for transmission to each game client 18 in decreasing order. When 
10 information packets are received by the game server 200 which have the same level of 
importance, the RV is then processed by the game software 206 to arbitrate which is to be 
transmitted first. The creator of the game software 206 must consider the relative importance 
of information when creating the game software to provide appropriate rules for arbitrating 
relative importance of information. 

15 

For example, in an air combar simulator game, game driver 204 is continually 
. transmitting some information to each game client 18. This information can be: Location(x, 
y, z); Heading(x, y, z); Global_Starus(Hit, Crashed, Exploding); LocaI_Status(Firing, 
Weapons, Burning, Control_Surface_Movement); etc. An RV for this information packet 

20 will include information for each piece of data which is appropriate to characterize it's 
relevance. The actual values in the RV array can be booleans, numerical values, flags or 
mixture of these types, as may be appropriate for the type of information they are associated 
with. When information packets have the same integer for the first value, Le % the same level 
of importance, the rest of the RV is then processed by the game software 206 to arbitrate 

25 which information packet is to be transmitted first. 

For example, the RV can contain the following information: 

Location: How far away is the sending aircraft from the receiving aircraft? Is the 

sending aircraft in the field of view of the receiving pilot? 
30 Heading: Is the sending aircraft heading towards or away from the receiving aircraft? 

If towards, how quickly are they closing? 
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Global_Status: If any defined evem is occurring, is it important?; and 
LocalJStatus: How important is an event to a particular client? This could, for 
example, depend upon physical distance for visual effects or the age of the information. 

5 One of the contemplated advantages of the present invention is that 

telecommunications network 16 can be the Internet or other network. However, such 
networks have problems in that the bandwidth available for transmission of a packet from 
communications server 12 to a game client 18 can change from packet to packet and certainly 
each time a new telecommunications link 24 is established. Further, depending upon the type 
10 of packet protocol employed, it is not always possible to certify delivery of a packet and/or 
the delivery order of a series of packets. For example, the packet protocol employed on the 
Internet is presently IP which provides for TCP packets and UDP packets. The delivery and 
delivery order are guaranteed for a TCP packet. In contrast, delivery and/or delivery order 
of UDP packets is not guaranteed. 

15 

While it is desirable to always employ TCP packets or the like, these typically result 
in a reduced overall useful throughput in telecommunication network 16 due to the protocol 
overhead and the bandwidth used to transmit the acknowledgement packets which are sent 
by the destination to confirm receipt of the packet. Therefore, in the embodiment of the 
20 present invention shown in Figure 1 , UDP packets are employed to maximize the useful 
throughput of telecommunication network 16. Accordingly, client software 106 and game 
software 206 are constructed with the assumption that telecommunication network 16 is 
"lossy 1 *, i.e. - some packets may not arrive at their intended destination, as is described 
below in more detail. 

25 

To achieve satisfactory performance regardless of the lossy nature of the transmission 
network, game server 200 performs a performance monitoring function 300 and a bandwidth 
aperture function 320, each of which is discussed below with reference to Figure 4. 



30 



In the performance monitoring function 300, the game server 200 attempts to monitor 
the available bandwidth of the connection between game server 200 and each respective game 
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client 18. Specifically, at step 302, game server 200 'floods' a connection to a respective 
game client by transmitting packets at an initial bandwidth predetermined by the capabilities 
of the transmission network, and varying the transmission speed up or down depending on 
the capabilities of the connection to a specific game client 18. In a manner somewhat similar 
5 [0 the PING utility of the IP protocol, information relating to the transmission time of these 
packets is reflected back to game server 200 and recorded. Alternatively, information 
relating to the transmission time of packets can be assessed on an ongoing basis without 
flooding the connection. 

10 The information reflected back to performance monitoring function 300 at server 200 

includes the total round trip transmission time. However unlike the PING utility, the packets 
are of a variety of sizes, rather than a fixed size, to more closely replicate the real world 
transmission of game data packets which are of variable length. The performance monitoring 
function 300 increase or decreases the transmission rate and records the transmission time 

15 for each packet sent back to game server 200. 

From the data produced in the above-described latency test, at step 304 the 
performance monitoring feature develops a set of metrics for each connection, including the 
bandwidth available and, more importantly, how the latency in the connection varies with 
20 bandwidth utilization and packet size. These metrics are used in conjunction with the 
aperture control function 320. The communications bandwidth is maximized to an optimal 
bandwidth until the predetermined maximum latency is exceeded. 

In general, the optimal bandwidth is determined by determining a maximum 
25 bandwidth at the predetermined maximum latency. If the maximum bandwidth is greater 
than the initial bandwidth, the initial bandwidth is increased to the maximum bandwidth. If 
the maximum bandwidth is less than the initial bandwidth, the initial bandwidth is 
incrementally reduced to the maximum bandwidth. The process is continuously repeated 
varying the optimal bandwidth. If the maximum bandwidth is outside predetermined limits 
30 at any time, the connection is terminated. 
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The predetermined maximum latency is set by the author of the game. Certain games 
can withstand greater latency than others. For instance, chess can have an extended latency 
whereas air combat games must have a very short latency. 

5 It will be understood by those of skill in the art that performance monitoring function 

300 will be performed each time a connection is established to a game client 18 and is 
assessed on an ongoing basis. Game server 200 continuously monitors each transmission of 
each information packet and will determine whether the latency is increasing or decreasing. 
In response, the bandwidth is varied so that the predetermined maximum latency is not 
10 exceeded. 

As will be apparent to those of skill in the an. transmission latency is an important 
consideration in implementing a multi-player computer hosted game and, specifically, 
interactions between players which are subject to large latencies are often unacceptable. For 

15 example, an unacceptable latency can result in one player in an air combat simulator shooting 
at another player who avoids the shot because he has moved to another location before the 
data representing the shot arrives at his game client 18 from game server 200. Accordingly, 
the present inventors have determined that game server 200 must give consideration to the 
metrics for both the available bandwidth and the latency characteristics for each connection 

20 and these metrics are used to derive a present optima! bandwidth for the connection at step 
306. As used herein, the term present optimal bandwidth refers to the bandwidth at which 
the best transmission bandwidth is obtained for a preselected maximum latency. 

As will be apparent to those of skill in the art, each of the game clients 18 may 
25 experience a different latency with the consequence that differeni game clients 18 will 
transmit and receive information at different rates. This is further complicated by the fact 
that the latency for each game client changes every time a new Internet connection is made. 
Moreover, each of the client system clocks 104 and game system clock 202 may be set to 
different times. Therefore, further associated with each information packet is a time stamp. 

30 
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Communications server 12 time stamps the information packet when it is inserted in 
the queue and sets an age limit on each information packet. In order that rhe time stamp 
associated with each information packet is consistent for each game client 18, the time stamp 
attached to each information packet is synchronized with the game client's client system clock 
5 104 by synchronization function 350. Each time game client 18 makes a new connection, 
a client time signal according to the client system clock 104 is sent to the game driver 14 
where the signal is received at a certain system time as indicated by the game system clock 
202 at step 352. Game driver 14 calculates the difference between the system time and client 
time at step 354. 

10 

When an information packet is being assembled for a specific game client 18. the 
difference calculated at step 354 is subtracted from the system time to arrive at the 
synchronized time sump in step 356. 

15 As mentioned above, game server 200 implements an aperture control function 320. 

Aperture control function 320 is used to proactively restrict and optimize the bandwidth of 
the data leaving communications server 200 to the present optimal bandwidth for rhe 
connection. Specifically, at step 322, game server 200 examines each ' information packet 
received from game driver 14 to determine its bandwidth requirements. 

20 

At step 324, game driver 14 examines the RV associated with each information packet 
and determines the relevance of each information packet relative to those others intended for 
the same game client 18. The information packets with the highest relevancy are inserted 
into a queue in decreasing order. 

25 

At step 326, if the time the information packet sits in the queue exceeds its age limit, 
then the information packet is discarded or deleted. Otherwise, the information packets 
remain in the queue and could be assembled into larger data packet(s) which will not exceed 
the present optimal bandwidth at step 328. Game server 200 assembles the information 
30 packets into one or more data packets and transmits the data packets to game client 18 at step 
330. 
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In the example RV given above, if an information packet relates to an aircraft which 
is firing its weapons, bui which is out of range of the aircraft flown by the player at a game 
client 18, then aperture control function 320 will queue this information packet if the present 
optimal bandwidth to game client 18 would be exceeded. If the aircraft is flying and there 
5 are several other aircraft flying, some nearer than others, then the information packets 
relating to the nearest aircraft are transmitted first and more frequently to the game client 18. 

The above-described embodiments of the invention are intended to be examples of the 
10 present invention and alterations and modifications may be effected thereto, by those of skill 
in the art, without departing from the scope of the invention. 
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We claim: 

i A game server for a multi-player game system, said game server comprising: 

a game driver for executing a multi-player game and generating game information for 
playing said multi-player game by at least one game client through a telecommunication 
5 network, 

prioritizing means for prioritizing said game information and responsively queuing 
said game information for transmission to said at least one game client, 

aperture control means for optimizing said game information for transmission to said 

at least one game client, and 
10 communications means for transmitting said game information through said 

telecommunication network to said at least one game client and for receiving processed user 
input through said telecommunication network from said at least one game client and 
transmitting said processed user input to said game driver. 

15 2. A game server as claimed in claim 1 wherein said aperture control means comprises 
monitoring means for detertnining an optimal bandwidth of a connection through said 
telecommunications network to said at least one game client: and 

limit means for limiting a bandwidth for transmission of said game information to said 
optimal bandwidth. 

20 

3. A game server as claimed in claim 2 wherein said monitoring means comprises 
means for flooding said connection with information to determine a latency 

characteristic of said connection; 

means for developing a set of metrics for said connection responsive to said latency 

25 characteristic; and 

means for assessing said set of metrics and responsively determining said opcimal 

bandwidth. 

4. A game server as claimed in claim 3 wherein said game information is generated in 
30 information packets, and said prioritizing means assesses each information packet, produces 

an array of values indicative of a relevance relative to other information packets for said at 
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Ieasc one game client and assess the array for queuing each information packet in order of 
highest relevance first. 

5. A game server as claimed in claim 4 wherein said game server has 
5 means for receiving a time signal from said at least one game client when said at least 

one game client connects with said game server through said network and determining a 
difference between a game server time and time of said at least one game client, and 
synchronization means for applying said difference to each information packet. 

10 6. A game server as claimed in claim 5 wherein said prioritizing means has 

means for setting an age limit for each information packet to remain in said queue, 

and 

means for discarding each information packet from the queue if said age limit is 
exceeded. 

15 

7. A game server as claimed in claim 6 wherein said game server has a plurality of game 
drivers, 

8. A game server as claimed in claim 6 wherein said game driver generates game 
20 information for playing said multi-player game by at least two game clients through a 

telecommunication network, and said prioritizing means prioritizes said game information 
and responsively queues said game information for each of said at least two game clients, and 
said aperture control means optimizes said game information for transmission for each of said 
at least two game clients. 

25 

9. A method of operating a multi-player game system having a game server 
communicating with a plurality of game clients connected through a telecommunications 
network comprising the steps of, for each game client: 

prioritizing game information generated by a game driver executing a multi-player 

30 game. 
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queuing said game information in order of priority for transmission to the game 

client, 

optimizing transmission of said game information to the game client, 
transmitting said game information through said telecommunicaiion network to the 
5 game client, 

receiving processed user input through said telecommunication network from the 
game client and transmitting said processed user input to said game driver, and 
repeating the steps for playing the multi-player game. 

10 10. A method as claimed in claim 9 wherein said step of optimizing comprises the steps 
of 

determining an optimal bandwidth of a connection through said telecommunications 
network to said game client; and 

limiting a bandwidth for transmission of said game information to said optimal 

15 bandwidth. 

11. A method as claimed in claim 10 wherein said step of determining an optimal 
bandwidth comprises the steps of: 

flooding said connection with information at an initial bandwidth to determine a 
20 latency characteristic of said connection; 

developing a set of metrics for said connection responsive to said latency 
characteristic; and 

assessing said set of metrics and responsively determining a maximum bandwidth at 
a preselected maximum latency, and if the initial bandwidth is less than the maximum 
25 bandwidth, increasing the initial bandwidth to said maximum bandwidth, and if said initial 
bandwidth is greater than said maximum bandwidth incrementally reducing the initial 
bandwidth to said maximum bandwidth and if the maximum bandwidth is outside 
predetermined limits, terminating the connection. 



i 
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12. A method as claimed in claim 11 wherein said step of determining an optimal 
bandwidth is repeated each time a new game client is connected to the game server through 
ihe telecommunications network. 

5 13. A method as claimed in claim 12 wherein said game information is generated in 
information packets, and said step of prioritizing comprises the steps of assessing each 
information packet for its relevance relative to other information packets for said game client, 
and queuing each information packet in order of highest relevance first. 

10 14. A method as claimed in claim 13 wherein said method further includes the steps of 
receiving a time signal from the game client when said game client connects with said 
game server through said network; 

determining a difference between a game server time and time of said game client, 

and 

15 applying said difference to each information packet. 

15. A method as claimed in claim 14 wherein said step of claim 14 is conducred on an 
ongoing basis. 

20 16. A method as claimed in claim 14 wherein said step of prioritizing includes the steps 
of 

setting an age limit for each information packet to remain in said queue, and 
discarding each information packet from the queue if said age limit is exceeded. 

25 17. An article of manufacture comprising: 

a computer usable medium having computer readable program code means embodied 

cherein for implementing a multi-player game playable by at least one game client connected 

through a telecommunications network, the computer readable program code means in said 

article of manufacture comprising: 
30 computer readable program code means for causing the computer to prioritize game 

information generated by a game driver executing a multi-player game. 
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computer readable program code means for causing the computer to queue said game 
information in an order of priority for transmission to the at least on game client. 

computer readable program code means for causing the computer to optimize 
transmission of said game information to the at least game client, 
5 computer readable program code means for causing the computer to transmit said 

game information through said telecommunication network to the at least one game client, 

computer readable program code means for causing the computer to receive processed 
user mput through said telecommunication network from the game client and to transmit said 
processed user input to said game driver. 

10 

18. The article of manufacture as claimed in claim 17 wherein said computer readable 
program code means for causing the computer to prioritize game information generated by 
a game driver executing a multi-player game includes computer readable program code 
means for assessing information packets of said game information, for producing an array 

15 of values indicanve of a relevance relative to other information packets for said game client 
and for assessing the array for queuing each information packet in order of highest relevance 
first. 

19. The article of manufacture as clatmed in claim 18 wherein said computer readable 
20 program code means to optimize transmission of said game information to the at least one 

game client, includes 

computer readable code means for flooding said connection with information to 

determine a latency of said connection; 

computer readable code means for developing a set of metrics for said connection 

25 responsive to said latency; and 

computer readable code means for assessing said set of metrics and responsively 
determining a maximum bandwidth at a preselected maximum latency, and for increasing an 
initial bandwidth to said maximum bandwidth if the initial bandwidth is less than the 
maximum bandwidth, and incrementally reducing the initial bandwidth to said maximum 

30 bandwidth if said initial bandwidth is greater than said maximum bandwidth and terminating 
the connection if the maximum bandwidth is outside predetermined limits. 
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20. The article of manufacture as claimed in claim 19 wherein said computer readable 
program code means for optimizing transmission of said game information to the at least one 
game client, further includes 

computer readable code means for receiving a time signal from the game client; 
5 computer readable code means for determining a difference between a game server 

time and time of said game client, and 

computer readable code means for applying said difference to each information 

packet. 

10 21. The article of manufacture as claimed in claim 20 wherein said computer readable 
program code means for optimizing transmission of said game information to the at least one 
game client, further includes 

computer readable code means for causing the said computer readable program code 
means for optimizing transmission of said game information to the at least one game client, 

15 to optimize on an ongoing basis. 

22. The article of manufacture as claimed in claim 19 wherein said computer readable 
program code means for causing the computer to prioritize game information generated by 
a game driver executing a multi-player game further comprises, 
20 computer readable code means for setting an age limit for each information packet to 

remain in said queue, and 

computer readable code means for discarding each information packet from the queue 
if said age limit is exceeded. 
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